home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc / Developer Documentation / Human Interface / Human Interface Q & A / HI Q&A #3 < prev    next >
Encoding:
Text File  |  1996-04-26  |  10.2 KB  |  228 lines  |  [ttro/ttxt]
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17. Q&A #3
  18.  
  19. By the Apple Computer OpenDoc Human Interface Team
  20.  
  21. As published in the March 1995 Apple Directions
  22.  
  23. At the recent Macworld Expo in San Francisco, where OpenDoc was on display,
  24. we heard several people ask, "So, what's the difference between a document
  25. and a part?" We thought you might be asking the same question. We also
  26. thought it would be helpful if we defined these and other commonly used
  27. OpenDoc terms. So, if you've wondered what the difference is between a
  28. document and a part or an application, editor, or viewer, read on.
  29.  
  30. The figure below shows a typical Macintosh desktop. It has some document
  31. icons, a Stationery folder, the SimpleText application icon, and the Disk
  32. First Aid application icon. Notice that the "Text Document" icon has been
  33. opened into a window. Because this is an OpenDoc-enabled document, it is a
  34. compound document--that is, a document that contains more than one type of
  35. content. (You can use the OpenDoc component architecture to create other
  36. things, as well. But we'll avoid that tangent for now.)
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Let's first take a look at the document icons. Even though some of them
  60. represent OpenDoc documents, they look the same as today's document icons
  61. because users don't need to distinguish OpenDoc documents from traditional
  62. documents. When users look at icons, they are typically trying to recognize
  63. a particular document, and are unlikely to remember whether the document was
  64. created using OpenDoc. The kind of document, such as drawing, text, or
  65. spreadsheet, is more important for recognition.
  66.  
  67. We did investigate ways to distinguish OpenDoc documents from documents
  68. created by traditional applications. The best solution we found was
  69. "badging" (putting a small identifying graphic element on top of an icon),
  70. but we found that even this didn't satisfactorily solve the identification/
  71. recognition issue. All of the badges we designed were either too small to be
  72. recognized, or so large that they overpowered other graphic elements on the
  73. icons, thus making it even harder to identify the kind of document. We
  74. finally realized that since OpenDoc documents will become the norm, rather
  75. than the exception, a badge to identify an OpenDoc document would soon
  76. become superfluous and we would want to remove it anyway.
  77.  
  78. We also investigated using badges to identify the primary type of document
  79. it is. For example, a badge might serve as a standard visual element to
  80. indicate that a document is fundamentally a spreadsheet, but can have other
  81. kinds of content embedded in it. However, using generic badges for each kind
  82. of part registered by CILabs (the organization responsible for promoting the
  83. OpenDoc technology) would mean that someone would have to create and control
  84. them, a difficult job in an area that is evolving so quickly. Ultimately, we
  85. determined that we should issue only one guideline--that document icons
  86. should look the same as they do today. We also wanted to give developers
  87. maximum space to use for designs of their own that might incorporate both
  88. kind and vendor, as is done today.
  89.  
  90. Now take a look at the menu bar in the figure. The menus are those you'd
  91. expect when editing a drawing--Layout, Arrange, and Pen. There are two
  92. differences, however.
  93.  
  94. First, the File menu is named Document. Today the File menu is used by
  95. documents, control panels, networking applications, and many other types of
  96. applications, so its meaning is vague. OpenDoc avoids confusion by
  97. consistently naming the first menu Document whenever an OpenDoc document is
  98. being worked on. We're considering a few other names for situations in which
  99. they make sense; for example, we may use Control for control panels.
  100. However, don't take this as license to invent lots of new menu names, which
  101. could cause as much confusion as using File in all situations.
  102.  
  103. Second, the Application menu icon (on the far right) displays a document
  104. icon rather than an application icon; in this figure it's a small SurfWriter
  105. document icon. That's because in the document-centered world of OpenDoc, the
  106. user is less concerned with what editor is running than with what document
  107. is active.
  108.  
  109. Now look at the document window itself. It represents an OpenDoc document;
  110. what distinguishes it visually from non-OpenDoc documents is the frame
  111. border around the active part--in this case, the drawing.
  112.  
  113. On the desktop you'll also see the SimpleText and Disk First Aid application
  114. icons. OpenDoc documents interoperate with documents from traditional
  115. (non-OpenDoc) applications--for example, you can copy content from a
  116. SimpleText document to an OpenDoc document. However, not all content in an
  117. OpenDoc document can be copied back to a document from a traditional
  118. application. Also, some tasks are still best handled by traditional
  119. applications--for example, a task that doesn't produce a record or document.
  120. On the other hand, if a traditional application were an OpenDoc part, it
  121. could be embedded into a document with instructions on how to use it, or
  122. placed in another useful context.
  123.  
  124. Finally, look at the Stationery folder. In the OpenDoc world, a user creates
  125. new documents by double-clicking stationery pads rather than by launching
  126. applications. In fact, the user rarely sees editor or viewer icons, since
  127. they are stored in a special folder. (A user deals with part editors only
  128. when installing them or substituting one part editor for another.) A user
  129. may move stationery to other places, but during installation of OpenDoc
  130. editors, all stationery pads are put into the Stationery folder to make it
  131. easy for the user to find them initially.
  132.  
  133. OpenDoc Terminology
  134.  
  135. Several terms commonly used in OpenDoc may be new to you; other OpenDoc
  136. terms are traditional terms used in new ways. We'll give you a quick intro
  137. to the terminology and a pointer to the complete set of terminology used in
  138. OpenDoc.
  139.  
  140. A document is a collection of OpenDoc parts assembled by a user or
  141. developer. A part becomes a document if it's dragged from its document to
  142. the desktop. A document becomes a part if it's dragged from the desktop into
  143. a different, open document.
  144.  
  145. A part is the fundamental building block of an OpenDoc document; it's the
  146. content that users see in their documents. An associated part editor is
  147. designed to allow the user to manipulate the part.
  148.  
  149. A part editor displays a part's content and provides a user interface for
  150. modifying that content. This user interface may include menus, controls,
  151. tool palettes, rulers, and so on.
  152.  
  153. A part viewer offers a subset of a part editor's functionality; it allows
  154. users to display and print a part's content but not to edit it. Viewers can
  155. be useful in document-sharing situations when the user who receives a
  156. document doesn't hold a license to the appropriate part editor.
  157.  
  158. Application refers to one of today's applications that has not been modified
  159. to support OpenDoc; these are also sometimes referred to as monolithic or
  160. traditional applications. We recommend that applications support the Drag
  161. Manager, because drag-and-drop capability is a feature that users really
  162. want. Supporting this capability also makes applications work better with
  163. OpenDoc.
  164.  
  165. A container application is a monolithic application that has been modified
  166. to support embedded OpenDoc parts.
  167.  
  168. * A part may be active or inactive. Being active means that the part
  169. contains the selection (or insertion point). For a part to be active, its
  170. contents must be visible--that is, displayed in a window or frame. Normally
  171. the active part receives commands and keyboard events, and its frame border,
  172. menu, palettes, and other user interface elements are displayed.
  173.  
  174. At most, one part is active at a time. A user activates a part by clicking
  175. it or by dragging something into the part's content. When a part is
  176. activated, the previously active part, if any, becomes inactive. An inactive
  177. part does not receive keyboard events or display its own interface elements,
  178. such as a menu bar, frame border, or palette. However, being inactive does
  179. not mean that a part isn't running; parts may execute asynchronously whether
  180. they are active or inactive, even if they are displayed as icons.
  181.  
  182. A frame is one of the two representations for a part (the other is an icon).
  183. A frame shows a representation of the part's contents. When you see a part
  184. inside a document, you see the part represented as a frame.
  185.  
  186. A frame border is a visible representation of a frame's shape and state.
  187. The border of a frame is displayed when the frame is active or selected; the
  188. border is invisible when the frame is inactive.
  189.  
  190. An icon is a representation of a part as a small generic picture along with
  191. a name. It is the normal representation when a part is shown in the Finder.
  192. The other possible representation is a frame.
  193.  
  194. Intrinsic contents refers to data that is intrinsic to a particular type of
  195. part. For example, text parts contain characters; graphics parts may contain
  196. lines and circles; video parts contain digitized video. The part developer
  197. determines what intrinsic contents a part may contain.
  198.  
  199. Embedding refers to the insertion of a part into the intrinsic contents of
  200. another part. The embedded part maintains its own part identity. The
  201. containing part controls layout issues, such as whether the embedded part
  202. overlaps existing parts in its contents.
  203.  
  204. A link is a relationship between two pieces of content. A link operation is
  205. a special kind of copy/paste operation, in which the pasted copy is updated
  206. every time the original changes. Links allow part contents to appear in more
  207. than one place; for example, a document might link in a picture from another
  208. document. Linked copies can even be displayed in different formats; for
  209. example, several linked copies of a spreadsheet might display the same data
  210. as a bar chart, a spreadsheet, and a pie chart.
  211.  
  212. In addition to contents, a part has properties--data items that describe the
  213. part. The user may modify some properties, such as name, comments, and the
  214. editor to use with the part. Other properties are set by the system, such as
  215. storage size, last modification date, and who modified the part.
  216.  
  217. * * *
  218.  
  219. We hope this FAQ has clarified the differences between documents and parts,
  220. given you clues about distinguishing OpenDoc documents from documents
  221. created by traditional applications, and introduced you to the OpenDoc
  222. terminology.
  223.  
  224. __________________________________________________________
  225.  
  226.  
  227. Copyright (c) 1995 by CILabs, Inc. All Rights Reserved.
  228.